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Field of the Invention 

[001] This invention relates to Internet bill presentment and payment 
environments and, more particularly, to methods and systems for delivering 
customer profile and billing information upon enrollment in such environments. 

Background of the Invention 

[002] Recurring bills (such as credit card bills, utility bills, and insurance 
bills) are traditionally mailed to customers by billers. Upon receiving bills, customers 
write checks (or provide some other monetary equivalent) and then mail the checks 
to the billers. This traditional scheme is inconvenient and time-consuming for both 
customers and billers. 

[003] Internet bill presentment and payment (IBPP) systems offer an 
attractive solution for the problems posed by traditional billing schemes. IBPP 
systems permit customers to view, store, and even pay recurring bills using a Web 
browser, e-mail, or personal financial management software. Because a biller, for 
example, simply posts the bill on-line, the biller avoids the inconvenience of having 
to print and distribute bills. Customers can view bills on-line, often at any time of day 
and at any point during the billing cycle. This convenience is not typically available 
in traditional billing schemes. Some IBPP systems also offer a service that enables 
customers to pay bills on-line without having to mail checks to billers, another 
convenience and time-saving over traditional billing schemes. 
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[004] Further, electronic payments are beneficial to both customers and 
billers. Customers are able to more accurately manage their personal finances 
because they know exactly when a debit will be made from an account to pay a bill 
electronically, as opposed to waiting for the corresponding biller to receive the check 
and then waiting for an associated bank to clear the check. Billers typically receive 
funds more quickly due to the electronic debiting. 

[005] Other benefits may also be realized by both customers and billers 
using IBPP systems. Enhanced customer service is one such benefit. For example, 
customers may access a list of frequently-asked questions from an IBPP Web site, 
submit change-of-address information using on-line forms, or submit billing 
questions or disputes using e-mail. In the traditional billing scheme, these tasks 
often required a customer to call a biller, typically resulting in a delay as the 
customer waited on hold for assistance from a representative of the biller. Billers 
may also be able to gather market intelligence based on customer profiles. While a 
traditional biller may know a customer's name and address, on-line registration at 
Web sites frequently includes additional questions, such as family status and 
household income. The biller may further use this demographic information to 
provide targeted marketing, either electronically, in the form of e-mail or banner ads, 
or by traditional mailings. 

[006] Additionally, IBPP systems provide new opportunities for revenue 
generation. For example, larger billers or banks may offer a hosting service for 
other, smaller companies' bills to attract customers to a one-stop bill payment 
environment. Not only does this consolidation provide additional convenience and 
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time-saving to customers, but the hosting service may permit a smaller company to 
provide electronic bills that would not otherwise have the means to do so. The 
customer and/or the smaller company may be charged a fee for this service, while 
the added expense to the larger biller is minimal. 

[007] More generally, a third party may provide IBPP service as a 
consolidator. Consolidators provide customers with access to billing data from one 
or more biliers. Consolidators may be billers and/or may act as intermediaries 
between customers and billers. For example, a customer may visit a single Web site 
of a consolidator to view and pay bills for both a utility company and a credit card 
company. The term "consolidator", as used in the following description, refers to any 
IBPP system that is requesting billing data. The term "biller", as used in the 
following description, refers to any IBPP system having billing data. 

[008] Enrollment in an IBPP program provided directly by a biller may 
permit customers access to billing data within minutes of registration. Because the 
customer is accessing the biller's own data via the biller's Web site, it may not be 
necessary to send an external request to obtain the desired information. On the 
other hand, enrollment in an IBPP program provided by a consolidator may involve a 
turnaround of days, or even a full billing cycle, before the consolidator can present 
billing data to customers. 

[009] One reason for delay is that requests, as well as billing information, 
are often sent between billers and consolidators in scheduled batches, for example, 
at the end of the day. In this situation, the best-case scenario would involve at least 
a delay of one day between initial registration with a consolidator and the first time 
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billing information is available for viewing. For example, at some point during the 
day, a customer enrolls in a consoiidator's IBPP program. The customer, upon 
enrolling, indicates one or more billers whose billing data the customer wishes to 
access on-line. At the end of the day, or whenever the batch requests are 
scheduled, the customer's request is fonA/arded from the consolidator to the selected 
biller(s). The biller(s) then determine if the customer's request is valid (i.e., if the 
customer has an account with biiler and if the account can be accessed and paid 
electronically). If a biiler determines the request is valid, the biller sends billing data 
to the consolidator with the next scheduled batch of data, or may wait until the next 
billing cycle. 

[010] Further, billers may index and/or store data in numerous different 
ways. Consolidators may be required to formulate different requests for each biiler 
to ensure accurate retrieval. Additionally, the retrieved data itself may need to be 
transformed, by either a biiler or a consolidator, for the data to be properly formatted 
for presentation to the customer. Thus, IBPP systems often must be biller- 
dependent, either incurring substantial overhead in cost and time by consolidators 
and/or billers or limiting the billers to which customers have access from a 
consoiidator's Web site. 
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SUMMARY OF THE INVENTION 

[01 1] It is therefore desirable to have a method or system that permits real- 
time delivery of customer profile and billing information in an IBPP environment. 
Further, it is desirable to have a method or system that minimizes the overhead 
incurred by the requesting IBPP system and/or the biiler by reducing the extent of 
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biller-dependent modules, or modules that must be designed specially for each 
biller. 

[012] Methods and systems consistent with the present invention provide 
real-time customer profile and billing information in an IBPP environment. 
Specifically, in a bill presentment and payment system with a scheduled time to 
communicate billing information with each one of a set of billers, a request, including 
the customer identification information, is provided to a biller, outside of the 
scheduled communication time. The biller provides billing information for that 
customer so the customer can access to the billing information at an unscheduled 
time with respect to the scheduled time for communicating with billers. 

[013] Further, in a bill presentment and payment system with a scheduled 
time for communicating billing information with a requesting IBPP system, there is 
provided a method for providing billing information. A request for information is 
received from a requesting IBPP system. The requested information is retrieved. 
The retrieved information is then fonwarded to the requesting IBPP system at an 
unscheduled time. 

[014] In accordance with one implementation of the invention, a system is 
provided for delivering information from a biller to a customer upon enrollment in an 
Internet bill presentment and payment environment. The system includes a 
consolidator module connected to a biller module. The biller module contains biller- 
independent submodules for communicating with the consolidator module and biller- 
dependent modules for retrieving information from data stored by the biller. An 
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interface is provided to permit the biller-independent submodules to interact with the 
biller-dependent submodules. 

[015] Additional features of the invention will be set forth in part in the 
description which follows, and in part will be obvious from the description, or may be 
learned by practice of the invention. It is to be understood that both the foregoing 
general description and the following detailed description are exemplary and 
explanatory only and are not restrictive of the invention, as claimed. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[016] The accompanying drawings, which are incorporated in and 
constitute a part of this specification, illustrate several implementations of the 
invention and, together with the description, serve to explain the principles of the 
invention. In the Figures: 

[017] Figure 1 is an exemplary Internet bill presentment and payment 

environment in which methods and systems consistent with the present invention 
may be implemented; 

[018] Figure 2 is a flow diagram illustrating communication of 

infomiation between entities in the bill present and payment environment as shown 
in Figure 1; 

[019] Figure 3A is a detailed block diagram of the consolidator server 

illustrated in Figure 1; 

[020] Figure 3B is a detailed block diagram of the biller server 

illustrated in Figure 1; 
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[021] Figure 4 is an exemplary flow chart illustrating the steps of a 

consolidator server process, consistent with the present invention; and 

[022] Figure 5 is an exemplary flow chart illustrating the steps of a 

biller server process, consistent with the present invention. 

DETAILED DESCRIPTION 

OVERVIEW 

[023] Systems and methods consistent with the present invention permit 
customers real-time access to billing information from one or more billers via a 
consolidator's Web site. Generally, customers receive goods, services, or value 
from a biller, and thus, owe the biller a sum of money. Billers typically have 
! information about the sum of money owed and may also have information 
associated with the transaction(s) leading to this debt. For example, if the biller is a 
credit card company, the biller may have information about the total amount owed 
and the amount of minimum payment required. The biller may also have further 
information, such as details about the credit card purchases made and any related 
finance charges. Similarly, if the biller is a utility company, the biller may have not 
only information about the amount owed, but also information about the usage of the 
utility. The biller may provide some or all of this infonnation to a consolidator, upon 
request, who displays the information to a customer. 

[024] Customers wishing to view billing information on-line may enroll in an 
IBPP program provided by a consolidator. Typically, customers may enroll with the 
consolidator via the consolidator's Web site. For example, selection of a 
"Registration" link on the consolidator's Web site may retrieve an on-line registration 
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form to be filled out by a customer. The on-line form may be composed of different 
fields, where the customer is prompted to enter identification information such as 
name, address, phone number, and social security number. Additionally, the 
customer may be prompted to enter information to select or identify billers for which 
they desire to utilize on-line billing services. For example, the customer may 
provide, for each chosen biller, the bilier's name, address, associated account 
number, and/or personal identification number (PIN). Alternatively, the customer 
may select from a list of predetermined billers provided by the consolidator. 

[025] Based on the identification and biller information provided by the 
customer, the consolidator formulates a request for each biller. The request is then 
sent to each biller immediately after formulation. The consolidator does not delay 
sending the request until some other time agreed in advance for communication with 
the biller. At each biller, the request may then be validated to ensure the request 
comes from an accepted source and/or contains sufficient data. Information, such 
as time of the request and data about the consolidator from which the request was 
received, may also be logged by the biller. Next, the biller generates an 
implementation object based on the request. The implementation object is biller- 
specific and is based on, among other things, how the biller stores data. 

[026] The implementation object validates the customer's credentials, such 
as by verifying the customer's name and account number. Following validation, the 
implementation object retrieves data from a data repository associated with the 
biller. Because the implementation object is biller-specific, it can retrieve the data, 
regardless of how it is stored in the data repository. The implementation object, 
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however, may transform the data into a format agreed upon by the consolidator and 
biller. The implementation object then sends the data to the consolidator, who 
displays the data to the customer. Unlike the biller, the consolidator does not 
maintain a long-term store of billing data; rather, the consolidator displays retrieved 
billing data to the customer. The elapsed time between sending the request and 
displaying the data is in the range of seconds to minutes. This provides the 
customer with real-time or near real-time access to billing data, as opposed to 
limiting customer access to billing data until after some later scheduled time when 
the biller may communicate with the consolidator. 

[027] The following description of implementations of this invention refers to 
the accompanying drawings. Where appropriate, the same reference numbers in 
different drawings reference same or similar elements. 

AN IBPP SYSTEM 

[028] Figure 1 illustrates an exemplary Internet bill presentment and 
payment (IBPP) system 100 that permits real-time access to customer profile and 
billing data. System 100 includes a customer computer 1 10, a consolidator server 
120, and a biller server 130 interconnected by network 140. Customer computer 
1 10 has an interface for accessing a consolidator's Web site. Consolidator server 
120 includes software to perform a process for communicating with customer 
computer 1 10 as well as instructions for communicating with biller server 130 and 
presenting billing data to customer computer 1 1 0. Biller server 1 30 includes 
software to perform a process for communicating with consolidator server 120. 
Network 140 may be the Internet, a local area network, or a wide area network. 
Although only one customer computer, one consolidator server, and one biller server 
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are illustrated as comprising the exemplary IBPP system 100, one skilled in the art 
will appreciate that the exemplary IBPP system 100 may include additional customer 
computers, consolidator servers, and/or biller servers. 

[029] Figure 2 illustrates communication flow between customer computer 
110, consolidator server 120, and biller server 130 over network 140. For example, 
customer computer 110 may send identification infonnation and/or requests for 
billing data 200 to consolidator server 120. In turn, after enrolling customer 1 10 and 
obtaining the billing data from biller server 130, consolidator server 120 may send 
billing data 210 to customer 110. Requests for billing data 200 and billing data 210 
may include instructions and/or data formatted in any language understood by both 
customer computer 110 and consolidator server 120. 

[030] Further, consolidator server 1 20 may send requests or, if already 
enrolled, billing data requests, 220 to biller server 130. Biller server 130 may 
respond to the request by sending detailed billing statements 230 to consolidator 
server 120. Requests 220 and detailed billing statements 230 may include 
instructions and/or data formatted in Biller Extensible Markup Language (Biller XML), 
for example, as provided in the Bill Data Exchange (BDX) protocol. Because the 
consolidator and the biller have a relationship whereby they agree to communicate 
using this language, requests and information may be sent outside of scheduled 
batches. For example, all of the above detailed communications take place outside 
of scheduled communication period 240. 

[031] BDX supports the following messages for communication between 
the consolidator and the biller: a message for the consolidator to begin interacting 
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with the biller (BDXSIGNON RQ/RS); a message for validating of the customer 
information (VALIDATECUSTOiVIER RQ/RS); a message for retrieving a customer 
profile (PRESCUSTOMERPROFILE RQ/RS); a message for retrieving a customer 
bill (PRESCUSTOMERBILL RQ/RS); and a message for retrieving both customer 
profile and bill data (PRESCUSTOMERDATA RQ/RS). In all of the above 
messages, the RQ suffix is used to denote a request, the RS suffix denotes a 
response. For example, a portion of a request to validate the customer may include 
the following code: 

<VALIDATECUSTOMERRQ> 
<CUSTOMER INFO 
</CUSTOMER INFO 
<A/ALIDATECUSTOMERRQ> 
[032] Figure 3A illustrates the consolidator server 120 in greater detail. 
Consolidator server 120 includes a central processing unit (CPU) 300 and a memory 
310. Memory 310 may include instructions for implementing an IBPP program, such 
as a bill presentment and payment (BPP) module 312, a client object 314, and a 
protocol library 316. Memory 310 may also include a web server 320 and a parser 
330. Web server 320 facilitates communication between consolidator server 120 
and biller server 130. Parser 330 permits consolidator server 120 to resolve 
instructions received from biller server 130 via Web server 320. 

[033] BPP module 312 facilitates the display of customer profile and billing 
information to a customer using a Web site and/or e-mail notifications. For example, 
a customer may log-in to a consolidator's Website and may choose from a list of 
enrolled billers. Upon selection of a biller, the system retrieves the data from the 
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biller, and displays on the customer's browser a bill, wliich may be formatted similar 
to a traditional paper-based bill. Further, there may be provided a link, such as a 
"Pay Now" button, that may provide electronic commerce capabilities. BPP module 
312 also includes a registration interface for new customers or for existing 
customers who wish to receive bills from additional blilers via the IBPP program. 
The registration interface may prompt the customer to enter Identification 
information, including customer name, address, phone number, or social security 
number, and account infonnation, such as biller name, address, and account 
number. 

[034] Client object 314 receives the identification and/or account 
information obtained by the registration interface of the BPP module 312. Using this 
data, client object 314 formulates a request. Client object 314 sends the request to 
biller sen/er 130 associated with each biller identified by the customer immediately 
after formulating the request. When the requested data is returned from biller server 
130, client object 314 may fonward the data to BPP module 312. 

[035] Protocol library 31 6 includes the necessary data and classes to 
implement a communication protocol between consolidator sen/er 120 and biller 
server 130. For example, Bill Data Exchange (BDX) protocol may be used to 
provide communication between consolidator server 120 and biller server 130. BDX 
protocol is similar to Internet Financial Exchange (IFX) protocol; however, BDX 
protocol uses Biller XML as a data format. The use of Biller XML as a data format 
permits the requested data to be sent directly to BPP module 312, which is also 
using Biller XML, without requiring further conversion. It should be understood, 



LAW OFFICES 

FiNNEGAN; Henderson, 

FARABOW, GARRETT; 
S DUNNER,L.L.P. 

I300 I STREET; N. V^. 
WASHINGTON; DC 20005 
202-4O8-4O00 



13 



LAW OFFICES 

F[MNEGAN, Henderson, 
Farabow, Garrett, 
8 dunner,l.l.p. 

13O0 I STREET, N. W. 
WASHINGTON, DC 20005 
202-'408-4000 



however, that any protocol understood by the consolidator server 120 and the biller 
server 130 may be used. 

[036] Similarly, Figure 3B illustrates the biller server 1 30 in greater detail. 
Biller server 130 includes a CPU 350 and a memory 360. Memory 360 may include 
instructions for receiving requests for and retrieving billing information, such as a 
server object 362, a request handler 364, an interface module 366, an 
implementation object 368, and a library 370. Memory 360 may also include a Web 
server 375 and a parser 380. Web server 375 facilitates communication between 
consolidator server 120 and biller server 130. Parser 380 permits biller server 130 
to resolve instructions received from consolidator server 120 via Web server 375. 
Biller server 130 is connected to data repository 390. 

[037] Server object 362 may be implemented as a servlet running on the 
biller server 1 30. Server object 362 receives enrollment and data requests from 
client object 314, running on consolidator server 120. Server object 362 may verify 
and validate a request, log information about the request, and then forward the 
request to request handler 364. Additionally, once the requested data has been 
retrieved, server object 362 fonwards the data to client object 314. 

[038] Request handler 364 receives the request from server object 362, 
and calls a specific implementation object 368, depending on the biller associated 
with the request. Implementation object 368 then implements interface 366. 
Interface 366 facilitates the use of different implementation objects 368 for each 
biller, while permitting the other components of system 100 to be independent of the 
biller. Interface 366 will interact with each implementation object 368 to determine 
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whether the customer's request is valid, and if it is, to obtain the customer profile and 
billing data. 

[039] Implementation object 368 may be responsible for validating the 
customer's credentials based on information stored in data repository 390, and for 
retrieving the requested data from data repository 440. Implementation object 368 
may vary for each biller, and may depend on how the particular biller indexes the 
data stored in data repository 390 and how the data is formatted. The same biller 
may have multiple implementation objects 368, if the biller has two or more data 
repositories 390 in which data is stored differently. If more than one biller stores 
data in the same manner, it is possible to reuse implementation object 368. Further, 
if implementation object 368 is so designed, it may be able to access data of 
different billers, even if the billers store data in different formats. 

[040] Library module 370 includes a protocol library, such as the BDX 
library described above, and/or any other library to facilitate communication between 
the consolidator application server and the biller application server. Further, library 
module 370 may include a mapping library, such as an ECX library, for mapping 
data from the format in which it is stored in data repository 390 (for example, in 
legacy format) to the format used by the bill payment and presentment module 312, 
such as Biller XML. 

[041] Data repository 390 includes a data storage device such as a 
database, a Lightweight Directory Access Protocol (LDAP) directory, or other file 
system. Data repository 390 is maintained and formatted by the biller. Preferably, 
data stored in data repository 390 is indexed based on customer information. 
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allowing for easy retrieval. Data repository 390 may reside on the same server as 
biller server 130, or may reside separately. 

[042] The system, as described above, is largely biller-independent in that 
most of the components are not created especially for a particular biller, but can be 
reused for all billers. The entire system is uniform but for the implementation object 
368. Interface 366 specifies the calls that will be made to the implementation object 
368, and the data expected. For example, interface 366 may include the call 
IsValidCustomei" , to which the expected response will include either "SUCCESS^' or 
"FAILURE'. The biller provides an implementation object 368, responsive to the 
calls specified by interface 366, that accesses the data repository 390 as formatted. 
How implementation object 368 determines whether a customer is valid or accesses 
data repository 390 to determine that information is transparent to interface 366 and 
the rest of system 100. Interface 366 simply specifies the calls and expects certain 
responses in return. Thus, the system is largely independent of the biller and how 
the biller indexes, formats, and stores customer identification and billing data. 

[043] Figure 4 illustrates the steps of a consolidator server 1 20, consistent 
with the present invention. First, consolidator server 120 receives registration 
information from a customer (step 400). For example, BPP module 312 may provide 
a customer interface on the consolidator's Web site. A customer may access this 
Web site and click on a "Register" button or other similar interface feature. Upon 
receiving the registration request, BPP module 312 may prompt the client to enter 
identification information and/or billing infomnation. For example, BPP module 312 
may prompt the customer to provide identification information such as the 



16 



LAW OFFICES 

FiNNEGAN, Henderson, 

FARABOW, GARRETT; 
Q DUNNER.L.LP. 

1300 I STREET; N, W. 
WASHI NGTON, DC 2O005 
202-408-4000 



customer's full name, address, telephone number, e-mail address, date of birth, or 
social security number. Additionally, the customer may be prompted to enter billing 
information, including the bilier's name, the biller's address, or the customer's 
account number. The customer may also be prompted to enter a password to 
ensure security on future visits to the consolidator's Web site. 

[044] Based on the information provided by the customer, client object 314 
will construct a request and send the request immediately to biller server 130, via 
Web server 320 (step 410). This request may be sent using the BDX protocol 
described above. The BDX protocol operates on HTTP/HTTPS, where HTTPS may 
be used for secure transmissions. For additional security, the request may also 
include client identification and a client password. The server object 362 may use 
the client identification and client password to validate the request, as well as to 
maintain a record of requests made by client object 314. 

[045] Shortly after sending the request, client object 314 will receive the 
requested data from the biller (step 420). This requested data may include the 
customer's profile and/or billing information. Depending on the type of consolidator, 
the billing information may include either full billing details or may include only a 
summary of billing details. If the request is denied by the biller, client object 314 will 
receive an error message. The error message may indicate a reason for the denial 
of the request. 

[046] The time elapsed between a customer submitting registration 
information and receiving the requested billing data may be represented as a 
summation of the time for the client object 314 to construct and send a request, the 
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round-trip network time for the request to travel to the server object 362 and the 
response to travel to the client object 314, the time to validate the request and 
retrieve the data from data repository 390, the time to transform data, and the time 
for the server object 362 to construct and send the response including the requested 
data to the client object 314. The times for constructing and sending the request 
and response are minimal. The round-trip network time is dependent on the network 
being used. The network time may also be minimized by running both the client 
object 314 and the server object 362 on the same instance of an application server. 
The time for retrieving the data may be minimized by if data repository 390 is 
indexed. The time to transfomri data depends on the complexity of the 
transformation map and the format of the data stored in data repository 390. 
Preferably, the total time elapsed is one minute or less. 

[047] Finally, the bill presentment and payment module 412 may provide 
the requested data to the customer (step 430). The customer is able to view their 
customer profile and billing infonnation via the consolidator's Web site. Additionally, 
the customer may be able to modify their customer profile. In this situation, BPP 
module 312 may provide the updated profile to the client object 314, which sends 
the updated information to server object 362 for further handling. The customer may 
also be able to pay the bill from the consolidator's Web site. 

[048] Figure 5 illustrates the steps of biller server 1 30 consistent with the 
present invention. First, server object 362 receives a request from client object 314 
(step 500). The request may include customer identification and billing infonnation. 
Additionally, the request may include client identification and a client password. 
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Server object 362 may ensure that the request is valid (i.e., from an authorized 
client, including sufficient information for processing). Server object 362 may also 
log information about the request, including, for example, the type of request, the 
source of the request, or the arrival time of the request. Server object 362 then 
forwards the request to request handler 364 (step 510). Request handler 364 will 
then call an implementation object 368, depending on the biller associated with the 
request (step 520). The implementation object 368 called by request handler 364 
will implement interface 366. Interface 366 permits interaction between 
implementation object 368 and the remainder of system 100, even though 
implementation object 368 is dependent on the biller. 

[049] Implementation object 368 then validates the customer's credentials 
(step 530). Implementation object 368 may compare parameters received as part of 
the request, such as social security number, name, account number, or other 
information with information stored in data repository 440. If there is no match, an 
error is returned to request handler 364. 

[050] If the customer's credentials are valid, implementation object 368 
retrieves the requested data, such as customer profile and/or billing information, 
from data repository 390 (step 540). Preferably, data stored in data repository 440 is 
sufficiently indexed by customer identification information to promote quick data 
retrieval. Implementation object 368 may also transform the retrieved data (step 
550), if the data as stored in data repository 390 is not in the same format as used 
by bill presentment and payment module 312. For example, implementation object 
368 may transform legacy data to Biller XML format using mappings included in an 
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ECX library stored in libraries 370. Finally, implementation object 368 passes the 
requested data to request handler 364 through interface 366. Request handler 364, 
in turn, passes the data to the server object 362, which returns the data to client 
object 314 for display by bill presentment and payment module 412 (step 560). 

[051] Other embodiments of the invention will be apparent to those skilled 
in the art from consideration of the specification and practice of the invention 
disclosed herein. It is intended that the specification and examples be considered 
as exemplary only, with a true scope and spirit of the invention being indicated by 
the following claims. 
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